fix(cli): use wall-clock timestamp for repository announcement updates - #2901

Linked Issue

Fixes #2876

Observed Failure

When executing buzz repos protect set or buzz repos protect remove on a repository announcement created more than 15 minutes ago, the relay rejects the event with:

relay error 400: invalid: event timestamp too far from server time

Root Cause

build_updated_repo_announcement in crates/buzz-cli/src/commands/repos.rs derived the replacement announcement event's timestamp strictly as existing.created_at + 1.
If the existing repo announcement was published more than 15 minutes ago, the derived timestamp existing.created_at + 1 was also more than 15 minutes in the past relative to server wall-clock time (now).
The relay enforces MAX_TIMESTAMP_DRIFT_SECS = 900 (±15 minutes) on all ingested events, causing any update to an announcement older than 15 minutes to be rejected as stale.

Implementation

Updated build_updated_repo_announcement to calculate the replacement event's timestamp as now.max(existing.created_at + 1):

• Strictly advances existing.created_at to satisfy NIP-33 parameterized replaceable event requirements.
• Uses current wall-clock time now when updating older announcements, eliminating timestamp drift rejection at the relay.

Regression Coverage

Added unit test protection_update_uses_wall_clock_time_for_stale_repo_announcements in crates/buzz-cli/src/commands/repos.rs verifying that repo announcements published in the past receive replacement timestamps matching current wall-clock time while advancing past the original timestamp.

Exact Validation Commands & Results

• . ./bin/activate-hermit && cargo test -p buzz-cli -> 251 tests passed
• . ./bin/activate-hermit && cargo fmt --all -> Clean formatting
• . ./bin/activate-hermit && just check -> Passed (clippy, formatting, desktop, web, and mobile checks clean)
• git diff --check -> Passed with no whitespace issues

Limitations or Untested Platforms

None.

Unrelated Changes

No unrelated changes were included.